Aminet 3/Aminet 3 - July 1994.iso/Aminet/disk/misc/dmafix.lzh/DMAfix.doc

Text File | 1991-12-16 | 13.7 KB | 270 lines

               DMAfix v1.0 Copyright 1991 Barry McConnell


This program is for anyone with an accelerator board which doesn't allow  DMA
into  its  32-bit  memory,  eg.  the  CSA  Mega-Midget  Racer,  or  the   SSL
A5000/B5000. It patches several DOS functions to make transfers to/from  your
hard drive much faster. It should work  on  any  Amiga  (A500/A1000/A2000  (I
presume no A3000 owner will ever need it...)), any OS (1.2/1.3/2.x), and  any
accelerator board. It was written entirely in 68000 assembly language.


Distribution:
~~~~~~~~~~~~~

This program is Shareware. If you like it (ie.  you're  getting  all  excited
about seeing your hard drive operating normally again...), please  feel  free
to send me a contribution. Since this program will greatly enhance the  power
of something which you probably paid a great deal of money for (68030  boards
with 32-bit RAM are *not* cheap!), I am  sure  you  will  find  it  extremely
useful to have around. The sum of 10 UK/Irish pounds (or  the  equivalent  in
any other currency) sounds reasonable to me; of course you can send  more  or
less as you see fit. I will of course  reply  to  everyone  who  sends  me  a
contribution, and let them know whenever I release an update. If you have  an
e-mail address,  I  can  automatically  mail  you  the  latest  version  when
available.

This program may be freely distributed as long  as  there  is  _no_  fee  for
doing so, and that this doc file  remains  with  it,  and  both  it  and  the
program remain unmodified. This means you may give (not  sell!)  it  to  your
friends, upload it to bulletin boards and FTP sites, but you may not  include
it in any PD library or distribute it as part of  a  commercial  package  (if
you are marketing an accelerator board, you  must  get  in  contact  with  me
first if you want to include this program with  it).  The  one  exception  to
this is that Fred Fish is given  permission  to  include  it  on  his  freely
distributable disk collection (but please e-mail me if you do this Fred!).


Disclaimer:
~~~~~~~~~~~

It works fine on *my* Amiga (I have the SSL A5000 68020 board, an  A590  with
a 52Mb Quantum, 1Mb of chip, 1Mb of 16-bit RAM, and 3Mb  of  32-bit  RAM).  I
have left it running permanently  on  my  system  and  it  has  never  either
crashed or destroyed any data on me. If it doesn't work for *you*, or  causes
you to lose valuable data, then don't jump on me: just let me know  what  the
problem is and I'll do my best to release a new version which cures it!

Be aware that this program modifies three very important  system  calls,  and
that it has the potential to cause  havoc  with  your  hard  drive.  However,
there is no "hacking" involved;  it  does  everything  in  a  system-friendly
manner. As I said, I have had no nasty experiences with it.

Of course, you will have done a complete backup before  using  this  program,
and will test  it  properly  before  relying  completely  on  it.  If  you're
_really_ paranoid, you can lock each of your  HD  partitions  before  running
it, eg.

lock dh0: on
lock dh1: on

I don't guarantee that every program ever written for  the  Amiga  will  work
with DMAfix; everything should, but there is a chance  that  something  might
not. All I can say is, it works with all my software, and I even ran my  disk
optimiser with DMAfix, and everything seems to be still intact... :-)

(Phew, disclaimer over; hope it didn't put you off using the program!)


Quick Installation:
~~~~~~~~~~~~~~~~~~~

If you don't want to have to read the rest  of  this  doc  file  (although  I
encourage you to do so), or just want to quickly see if  it  works,  then  go
into a Shell/CLI and type:

makedir ram:dma
assign dma: ram:dma
run DMAfix

Now try booting an application, or copying a large file to the RAM  disk,  or
running something like DiskSpeed, and notice the difference!!

To quit, type break <task>, where <task> is the process ID  of  DMAfix  (type
status to find this out). Note that this 'quick' method of installation  will
only work if the  offending  32-bit  memory  is  outside  the  16Mb  (24-bit)
address space; if you have non DMA-able memory inside the 16Mb  space  (quite
unusual, I think), then you  will  need  to  read  the  next  section  before
running the program...


How to Install:
~~~~~~~~~~~~~~~

Boot HD-Toolbox (or the equivalent for your system)  and  check  the  Address
Mask for your controller  (in  HD-Toolbox,  go  to  Partition  Drive/Advanced
Options/Change File System, and note down the Mask  parameter).  This  number
tells the FileSystem where it can DMA to. Pad it out with  leading  zeros  if
necessary to form 8 hex digits (eg. mine is fffffe (ignoring the  0x  at  the
start), so it becomes 00fffffe), and use that as the one and  only  parameter
which DMAfix takes (eg. run DMAfix 00fffffe). This  number  is  actually  the
default if you don't enter any parameter, since the problem generally  occurs
with memory outside the 16Mb address space.

I recommend running this program from your Startup-Sequence; as near  to  the
beginning as possible.


The Problem:
~~~~~~~~~~~~

This section is for those of you who  don't  actually  know  why  their  hard
drive  performance  suffers  so  much  with  non-DMA  32-bit   memory.   This
information was posted by Mike Sinz of  Commodore  (hi  Mike!)  on  Usenet  a
while back; I'll summarize it.

When the  FileSystem  notices  that  an  application  has  requested  a  data
transfer from your hard drive into memory it cannot DMA into  (generally  32-
bit memory outside of the 16Mb address space), it has  to  do  some  "magic".
What it does is set up a 512-byte buffer down in low memory (16-bit fast  RAM
or chip RAM) where DMA does work, and repeatedly DMAs into that  in  512-byte
chunks and CPU-copies them up to the buffer in high  memory.  There  are  two
speed hits here. The obvious one is the overhead in having to copy  all  that
data around (although in practice, an  '020/'030  is  pretty  fast  at  doing
this, even when 16-bit RAM is involved). The  other  one  (which  causes  the
most slowdown) is reading only half a K chunks  off  your  hard  drive  at  a
time, as it is a LOT faster to read, say, 128K at once  than  256  blocks  of
512 bytes.


The Solution:
~~~~~~~~~~~~~

Simple, increase the buffer size down in low memory! Unfortunately, the  size
of this buffer is hardcoded into both the 1.3 and 2.0 ROM  (in  actual  fact,
it's based around the size of one sector, so it's  not  simply  a  matter  of
changing a 512 to a 65536...). I didn't  feel  like  disassembling  ROMs,  so
another method had to be used.

What my program does is  patch  three  DOS  functions:  Read(),  Write()  and
LoadSeg(). For Read(), it basically asks the question "Is the user trying  to
DMA more than 512 bytes into 32-bit memory?" and  if  the  answer  is  "yes",
then it sets up its own (big!) buffer in low (chip) memory, and goes  into  a
loop calling the original Read() to get data into that buffer, and then  CPU-
copying it up to the original buffer. Ideally, it only has to do one  Read(),
as it first tries allocating enough memory for the whole amount  of  data  to
be read, then tries 256K, then 64K, then flashes the  screen,  gives  up  and
jumps back into the original function... The procedure for Write() is  pretty
similar: it does the same in  reverse,  ie.  CPU-copies  the  data  into  the
temporary buffer before DMA-ing out to your hard drive.

Unfortunately, LoadSeg() doesn't call  Read()  via  the  normal  vectors  (it
calls Read() directly; naughty naughty!),  so  it  will  still  be  painfully
slow. I had to think of another way to get around this. The solution  I  came
up with was to copy the file into the RAM disk  (using  a  256K  (or  64K  if
memory is low) DMA-able buffer so it's fast!)  and  then  LoadSeg()  it  from
there. It works, and isn't as slow as you'd think it would be! Note  that  it
uses the assignment dma: when copying the file, so this is why  you  have  to
assign this to  somewhere  (unused)  in  the  RAM  disk  before  running  the
program.


Speed:
~~~~~~

This program will make your hard  drive  perform  so  close  to  how  it  was
originally  with  the  68000  that  you  should  not  be  able  to  tell  the
difference. Using DiskSpeed 4, I have seen that speeds are to within  10%  of
what they were originally. Booting  applications  gives  similar  performance
too, even though they have to  be  copied  to  the  RAM  disk  first.  As  an
example, booting DPaint without DMAfix takes about 10 seconds;  with  DMAfix,
it is a little over 2 seconds (slightly slower  than  in  68000  mode).  With
DiskSpeed 4, I get 573K/sec in 68000 mode, 36K/sec (!) in 68020 mode  without
DMAfix, and 527K/sec with DMAfix. When DMA-ing into chip RAM in  68020  mode,
I get 706K/sec, which is a good indication of how fast you would  be  without
the DMA problem, and also shows that there isn't  too  high  an  overhead  in
copying all the data around (around a 25% slowdown).


Problems/Features:
~~~~~~~~~~~~~~~~~~

This program is very memory-intensive. If you request a  1Mb  file  transfer,
it will first try AllocMem()ing 1024K, and if it fails it will try 256K,  and
finally 64K before giving up. (The screen will flash  if  this  happens.)  Of
course, this will have to be chip RAM (I'm working on a  routine  which  will
allocate 16-bit fast RAM if available): it might be a good idea to make  sure
you have plenty of this free. With only 512K of it, you  might  be  a  little
pushed at times (although if you are getting to the point at which  there  is
less than 64K available, a slow hard drive is going to be the least  of  your
worries...), but I find with 1Mb of chip,  I  rarely  run  out.  Maybe  in  a
future version I will allow even smaller buffers (even an 8K buffer  will  be
reasonably fast), or a fixed (large) buffer defined at startup time.

At this point you may be muttering things like "memory  fragmentation";  well
it shouldn't affect fragmentation too  much  as  it  deallocates  the  memory
pretty quickly  (hopefully  no  other  task  has  asked  for  memory  in  the
meantime!).

The worst-case scenario comes when you try to boot  something  like  ProPage.
It will try to allocate 450K so it can copy the  application,  and  use  this
buffer to get it into the RAM disk (another 450K of 32-bit  RAM  this  time).
The original 450K buffer will then be freed, and ProPage will be  booted  off
the RAM disk (immediately taking up  yet  another  great  chunk  of  memory).
Unfortunately when it then tries to delete ProPage from the RAM disk it  will
fail, as ProPage is one of the (few?) applications which uses overlays.  This
means that the file will still be open, and it cannot delete it until  either
ProPage closes it, or you quit ProPage. In actual fact, it  tries  to  delete
it every time you boot another application, and  should  eventually  succeed.
ProPage and MRBackup are the only programs which  I  have  seen  having  this
problem. Of course, if you're into DTP  then  you  probably  have  a  lot  of
memory to play around with, so you won't mind. :-)  If the  file  refuses  to
go away, you can of course delete it manually (as long as  it  is  not  still
open; you'll get  an  error  message  if  it  is...).  If  you  find  that  a
particular application always leaves its file in dma: even after quitting  it
and booting  something  else,  then  please  let  me  know.  (This  shouldn't
happen!)

Anyway, the point I'm trying to get across is that you will  need  plenty  of
memory to make full use of DMAfix. It will work no  matter  how  much  memory
you have free, but the more memory it can grab, the faster it will be...

The patches would normally affect _all_ reads and  writes;  even  when  using
the RAM disk or the console! Hence, I have put in a  few  additional  checks.
If the filehandle passed to Read() is the same as the current Input()  stream
(or the filehandle passed to Write() is  the  same  as  Output()),  then  the
original function is used instead. If the first three letters of  the  device
in question are "RAM" (case insensitive, so it could also be  Ram),  it  uses
the original function too. So make sure your RAM disk(s) volume  names  begin
with "RAM", and your hard disk partitions don't! :-)  I know  it  will  still
intercept calls to the floppy drive - sorry! However  floppies  are  so  slow
anyway that you won't notice the difference. ;-)

The program really likes 2.0! While it works under 1.3, I have  noticed  that
some things (eg. the Copy command) don't appear to take full advantage of  it
and are still very slow. Also I don't know how to easily find out the  volume
name of the filehandle under 1.3 (there's a  function  called  NameFromFH  in
2.0), so you will find your RAM disk a bit slower (for me, it goes down  from
5Mb/sec to 1Mb/sec; so it's still very fast...).


Credits:
~~~~~~~~

Well, the program was obviously written by me, but a special  thanks  has  to
go to Eddy Carroll who helped me out whenever I got stuck (frequently!),  and
who also gave me some ideas on how to do it in the first place.  Since  I  am
relatively new on the Amiga scene, and this is only my  second  project  (the
first one hasn't been finished yet; I put it on 'hold' to do this...), I  had
a LOT of questions for him about the intricacies of the Amiga system.


Contacting me:
~~~~~~~~~~~~~~

If you have any bug reports, suggestions, comments,  questions  or  money,  I
can be reached at:

Snail mail:  Barry McConnell,
             "Piper's Hollow",
             Hillcrest Road,
             Dublin 18,
             Ireland.

Internet:    [e-mail]  [that's double-el and unix-one!]
             [e-mail]  [will be forwarded to my UNIX account]

I don't envisage any of these addresses changing before the end of 1995!!

No, don't tell me this doc file is longer than the program itself... :-\